Various forms of network storage systems exist today, including network attached storage (NAS), storage area networks (SANs), and others. Network storage systems are commonly used for a variety of purposes, such as backing up critical data, data mirroring, providing multiple users with access to shared data, etc.
A network storage system includes at least one storage server, which is a processing system configured to store and retrieve data on behalf of one or more client processing systems (“clients”) that are used by users of the network storage system. In the context of NAS, a storage server is commonly a file server, which is sometimes called a “filer”. A filer operates on behalf of one or more clients to store and manage shared files. The files are stored in a non-volatile mass storage subsystem (which is typically external to the storage server, but does not have to be) which may include one or more arrays of non-volatile mass storage devices, such as magnetic or optical disks or tapes, by using RAID (Redundant Array of Inexpensive Disks). Hence, the mass storage devices in each array may be organized into one or more separate RAID groups.
In a SAN context, a storage server provides clients with access to stored data at a sub-file level of granularity, such as block-level access, rather than file-level access. Some storage servers are capable of providing clients with both file-level access and block-level access, such as certain Filers made by Network Appliance, Inc. (NetApp®) of Sunnyvale, Calif.
Caching is a technique that is commonly used to reduce latency associated with accessing data in computer-related applications, including in network storage systems. For example, the main memory (i.e., random access memory (RAM)) of a storage server is often used as a cache logically between the storage server's main central processing unit (CPU) and the non-volatile mass storage (e.g., disk) subsystem, since the RAM which forms the main memory generally has a much smaller access latency than the disk subsystem. Accordingly, the main memory of a storage server is sometimes called the “buffer cache” or, simply, the “cache”. Note that this kind of cache should not be confused with other forms of cache memory known as level-1 (“L1”) cache, level-2 (“L2”) cache, etc., which are commonly used by a microprocessor (and typically implemented on the same chip or the same motherboard as the microprocessor) to reduce the number of accesses to main memory. In the context of this document, the buffer cache (or simply “cache”) of a storage server is the main memory of the storage server.
Some network storage servers also employ an additional level of caching logically between the buffer cache (main memory) and the non-volatile mass storage subsystem; this additional cache is known as a “victim cache”. In the context of this document, a “victim cache” is a cache that holds some of the data blocks (“victims”) most recently evicted from a main or primary cache, i.e., from the main memory of the storage server. The main memory in a storage server (or at least a portion of the main memory) is in certain instances called the “main cache” in this document, to distinguish it from the victim cache.
A victim cache in a storage server is generally a medium-size auxiliary storage facility that is faster than normal RAID disk storage, but slower than main memory. Such a victim cache might be implemented on, for example, an external memory card, using solid state disks (SSDs) or other types of storage devices. The size of such a cache can range from, for example, a few GBytes up to hundreds of GBytes or more. When a data block, or “buffer”, is needed but not found in main memory, the victim cache is consulted prior to loading the buffer from RAID disks. Note that the terms “buffer” and “block” (or “data block”) are used herein interchangeably.
Certain data blocks handled by a storage server are very important, such that it is desirable to be able to access those blocks quickly even after they have been evicted from the main cache; an example is blocks that contain system metadata. Other blocks may be less important and need not be as readily accessible after eviction from the main cache. Currently, there is no known ability to intelligently determine which blocks should or should not be stored in the victim cache upon eviction from the main cache, based on the type of data they contain. As a result, the failure to cache some important blocks combined with the unnecessary caching of less important blocks tends to degrade the overall performance of the storage server. In addition, there is a need to be able to customize victim caching for application-specific workloads.